Programmazione in Elixir: Processi con Stato e Ottimizzazione delle Chiamate di Coda

In Elixir, i processi sono di durata breve per impostazione predefinita; una volta terminata una funzione, il processo si interrompe. Per creare un processo persistente con stato, utilizziamo la ricorsione per mantenere vivo il processo in un ciclo.

1. Ottimizzazione delle Chiamate di Coda (TCO)

Se l'azione finale assoluta di una funzione è quella di chiamarsi da sola, la VM Erlang (BEAM) esegue Ottimizzazione delle Chiamate di Coda. Invece di aggiungere un nuovo frame allo stack, semplicemente salta indietro all'inizio della funzione con nuovi argomenti.

def fattoriale(n, acc), do: _fatt(n-1, acc*n) # TCO
def fattoriale(n), do: n * fattoriale(n-1) # NON TCO

2. Stato Persistente

Lo stato viene mantenuto passando valori aggiornati come argomenti alla chiamata ricorsiva. Grazie alla TCO, questi argomenti sostituiscono i parametri originali nello stack senza consumare memoria aggiuntiva, permettendo ai cicli di continuare indefinitamente.

TERMINALbash — 80x24

> Ready. Click "Run" to execute.

QUESTION 1

What is the primary requirement for Tail-Call Optimization to occur?

The function must use the 'loop' keyword.

The recursive call must be the absolute final expression executed.

The function must be defined inside a module.

Arguments must be integers.

QUESTION 2

Exercise: WorkingWithMultipleProcesses-1. Run the Spawn1 and Spawn4 code. See if you get comparable results. What is the observable difference?

Spawn1 crashes after one message; Spawn4 stays alive.

Spawn1 is faster than Spawn4.

Spawn4 uses more memory over time.

There is no observable difference.

QUESTION 3

In pmap, we assign 'self' to 'me' before spawning. Why?

To make the code more readable.

Because 'self' inside a spawn block refers to the child process PID.

To bypass the Pin operator requirements.

QUESTION 4

Use spawn_link to start a child that sends a message and exits. If the parent sleeps for 500ms before receiving, what happens to the message?

The message is lost because the parent wasn't waiting.

The message is stored in the parent's mailbox until processed.

The parent crashes immediately.

QUESTION 5

Is the order of replies in concurrent processes deterministic in theory?

Yes, they always arrive in spawn order.

No, it depends on the scheduler and execution time.